Demandlib 0.2.2: VDI and BDEW25

If a rough estimate for energy demands is just good enough, standard load profiles can be handy. To easily generate these kinds of profiles, we have the “demandlib” in the oemof cosmos. This week, we released a new iteration that includes profiles as defined by the VDI (Verband Deutscher Ingeneure, Association of German Engineers) and the updated profiles by the BDEW (Bundesverband der Energie- und Wasserwirtschaft, German Association of Energy and Water Industries).

Continue reading “Demandlib 0.2.2: VDI and BDEW25”

2025.02 dev meeting retrospective

At the last developer meeting, in sunny Flensburg, we focused on decision making and drafting for the future development of solph. Here are the main results:

  • There is consensus that we should have common approach of facades or sub-networks. Currently, there are several similar implementations, namely facades in oemof.tabular, nested energy system object (used for cellular approaches, now removed), and node containers (in MTRESS).
  • We worked hands on at the documentation. Improvements will be merged to the v0.6 dev branch. We also have a suggested colour palette to use in examples:
    Lapis Lazuli (#1F567D) , Cambridge blue (#8AA8A1), Pumpkin (#FA8334) , Rose (#FF006E), Icterine (#FFFD77)
  • We drafted a new class Results that will eventually replace the nested dict generated by solph.processing.results().
  • Before thinking about alternative back-ends to Pyomo, we should remove code duplication.
Group picture taken at the balcony of the FH Flensburg building near the habour.

oemof AUA 2025/03 (today)

As announced previously on other channels, we have an “ask us anything” session today. Unfortunately, we currently experience issues with the server that runs our cloud infrastructure, including the calendar. Thus, the link we originally shared is currently unavailable. So, here is a summary:

Job offer: Join Our Open Source Energy Community!

Hey there!

(Update April, 29th: We found somebody for the described position. As nobody of us except our new team member is compensated by the oemof association, we of course still welcome everybody who is willing to contribute. Best ways to do so are probably joining discussions at openmod:oemof and helping to develop and maintain oemof at GitHub.)

Are you a student or do you have a passion for energy systems and programming? If you love diving into Python projects and exploring innovative ways to optimize energy systems, we’d love to have you on board.

What You’ll Do:

  • Discover & Share: Search the web for fresh publications and real-world applications of oemof, our collection of open source tools.
  • Connect & Learn: Chat with users—from scientists to business professionals—to learn how they’re using energy system optimization.
  • Create & Engage: Write fun, engaging blog posts about your discoveries and share them on social media.

What We’re Looking For:

  • A communicative, curious individual who loves talking to people.
  • A motivated explorer who’s excited to learn about the latest in science and tech.
  • Ideally, you already know a bit about oemof—but if not, that’s cool too!
  • Fluent English skills to engage with our community.

What’s in It for You?

  • A chance to work some hours a month.
  • An opportunity to be part of a vibrant, collaborative open source community.
  • A space to develop your communication and technical skills while making a real impact in the world of energy system optimization.

Does this sound like something you want to do? Send us an email at info@oemof.org. Tell us who you are—what your main job is or, if you’re studying, what you’re studying—and let us know if you’ve ever had contact with oemof. We’re totally open to oemof beginners!

We can’t wait to hear from you!

oemof ask us anything: 2025-02-27

After premier of the “oemof consultation hour” we spontaneously decided to have a short AUA (ask us anything) this Thursday at 16:30 CET. We will try to use our own video call infrastructure (at cloud.oemof.org/call/). So, if you have questions, just dial in and get answers live from the 2025.02 developer meeting.

oemof consultation hour

Next week, at the 30th of January, we will have our first oemof consultation hour from 2 pm to 3 pm CET. To keep the entry barrier low, we plan to have it at https://meet.jit.si/oemof-consulation-hour. Feel free to join, if you have questions or just want to chat about oemof. (Note that there is something similar for the TESPy community for some time now.)

2025.02 dev meeting: Save the date

We just got the feedback that the next oemof meeting will be hosted by the Flensburg University of Applied Sciences from February 26th to 28th. To push the further development of oemof, it will come as a more developer focused meeting. Save the date and contribute, if you are interested! (Beginners, in particular first-time contributors, will get guidance, of course.)

Update: We created a wiki page for the Meeting 2025.02 to work on the agenda.
Update 2: To register, you can either add your name to the linked Wiki page at GitHub, comment this post, or write an email to meetings@oemof.org.

Report from the anniversary meeting

The last days, we had our semi-annual meeting to discuss the state of open energy system modelling. This time in the flavour of a user meeting with a special 10-year celebration event. I am so happy that I can tell that the concept worked out: We had almost 40 guests, some of them were on their first oemof meeting. Still, they dynamically formed sub-groups for parallel sessions, had fruitful discussions, shared experiences, and eventually started implementing something together. To kick this off, we asked every participant to give a short pitch at the first day. This was quite a ride, but due to coffee breaks and a poster session in the DLR entry hall, it was possible to identify many persons you wanted to talk to later.

Group photo of those who stayed long enough on Thursday (after the 10-year celebration event). Unfortunately, we forgot to take a picture before.
Continue reading “Report from the anniversary meeting”

Interactive solph graph using Dash

Modelling energy systems as graphs, as we do it for oemof, is a rather clear approach. It can help understanding energy flows and the overall network structure. However, in highly complex systems keeping of all the components track becomes increasingly difficult. To tackle this, Tobias Hörter and Andreas Wunsch from Fraunhofer IOSB have created an interactive plotting tool.

The example can be found as a Snippet at the Faunhofer GitLab. The code enables visualization of the system and representation of the component’s parameters upon the model-creation.  They use a combination of NetworkX and Plotly DASH Cytoscape for this purpose. The parameters of the model components are first extracted and a NetworkX model is created from the solph energy system afterwards. This network is then used to make cytoscape elements, which are necessary to enable DASH-Plotly to visualize the network.

When running the Dash-App, the user can rearrange the system via drag and drop. Additionally, when clicking on the system components, the parameters of the respective component are displayed. Do you like this approach? How do you draw the energy system graph if you need it?

New solph release: v0.5.4

We released two new versions of solph. One is a stable maintenance release (solph 0.5.4 at PyPI, solph v0.5.4 at GitHub), the other is a packaged preview for the next release (solph 0.6.0a1 at PyPI). In the actual release features the following changes:

  • Consistency
    • Allow sinks/sources to have multiple inputs/outputs
    • Allow lower limit for generic_integral_limit
  • Fixes
    • Display inline math correctly and hint towards the usage of the inbuilt slope and offset calculation methods (OffsetConverter)
    • Adapt to new Pandas API and fix warnings
    • Formulate full_load_time docstring specific for energy
  • Improvements “under the hood”
    • Introduce variable for storage losses
    • Replace _Sequence by _FakeSequence

We decided to have an alpha version packaged as well, which mostly changes the way storage_costs are considered. Before, we took into account every time step, which eventually leads to double weighting of the initial/last time step if the storage is balanced (i.e. first and last time step are the same). As the previous implementation wasn’t really broken in all cases, the new way is not strictly a fix. And as it will lead to different results compared to the previous implementation, the change shouldn’t be part of the v0.5 release. So, if you want to consider storage costs, this release is just for you.